Skip to content

workspace: make Quarto PR preview robust (un-failable comment + correct URL on private repos)#94

Merged
jbragg merged 2 commits into
mainfrom
fix-quarto-preview-robustness
Jul 17, 2026
Merged

workspace: make Quarto PR preview robust (un-failable comment + correct URL on private repos)#94
jbragg merged 2 commits into
mainfrom
fix-quarto-preview-robustness

Conversation

@gas2own

@gas2own gas2own commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Why

A freshly scaffolded workspace repo's very first PR looked broken to a new user — red docs / deploy check, no preview link posted — even though the site published to gh-pages fine. Root cause is two latent bugs in the shared reusable workflow (workspace-quarto-site.yml), both surfaced while onboarding a freshly scaffolded private workspace repo.

Bugs fixed

  1. Transient API error reds an otherwise-successful deploy. The preview-comment existing=$(gh api …) read was unguarded under set -e. A GitHub 5xx returns an HTML body that --jq can't parse (invalid character '<' looking for beginning of value), aborting the step after publish succeeded. The block is documented as best-effort but wasn't. Now the whole block runs under set +e and closes on a guaranteed-success command — a comment hiccup can at most drop the comment, never red the deploy.

  2. Wrong preview URL on private/internal repos. The URL was hardcoded to <owner>.github.io/<repo>. Private/internal repos serve Pages from an obfuscated <random>.pages.github.io domain, so that link is dead there. Now the URL is resolved from the Pages API (.html_url) with a fallback to the canonical form; the deploy job and the scaffold docs.yml template grant pages: read.

Blast radius

Both flow fleet-wide since scaffolded repos track this workflow at @main. Existing repos get correct private-repo preview URLs after adding pages: read to their docs.yml (graceful fallback until then).

Supersedes #92 and #93 (consolidates the preview-comment robustness work into one PR). #91 (bootstrap main first on empty repos) is a separate, complementary onboarding fix.

🤖 Generated with Claude Code

…ct URL on private repos)

Two latent bugs in the reusable Quarto deploy workflow made a freshly
scaffolded repo's first PR look broken (red deploy check, no/wrong preview
link) even when the site published fine:

1. The preview-comment gh api read was unguarded under set -e; a transient
   5xx HTML body breaks --jq and abORTS the deploy after publish. Now the
   block runs under set +e and closes on a guaranteed-success command.
2. The preview URL was hardcoded to <owner>.github.io/<repo>, dead on
   private/internal repos that serve from an obfuscated *.pages.github.io
   domain. Now resolved from the Pages API with fallback; deploy job and
   scaffold docs.yml template grant pages: read.

Supersedes #91, #92, #93.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When Pages isn't configured on a repo, GET /repos/{repo}/pages returns 404
and gh prints the raw error JSON to stdout instead of applying --jq, so the
previous non-empty check let that error text flow into the preview link.
Validate that the resolved base is an https URL before using it, falling back
to the canonical <owner>.github.io/<repo> form otherwise.
@jbragg
jbragg merged commit ce20578 into main Jul 17, 2026
7 checks passed
@jbragg
jbragg deleted the fix-quarto-preview-robustness branch July 17, 2026 05:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants